コンポーネント・モデル基盤の仮想ソフトウェア・プラットホームを生成する方法、これを利用してソフトウェア・プラットホーム・アーキテクチャを検証する方法及びその装置

专利摘要:
コンポーネント・モデル基盤のソフトウェア・プラットホーム・アーキテクチャの検証方法に係り、ソフトウェア・プラットホームの設計情報によって、少なくとも一つ以上のコンポーネントの機能を記述するテンプレートコード、及びソフトウェア種類による設定変数が備わり、前記生成されたテンプレートコードのビルドを行うビルドスクリプトを具備する仮想ソフトウェア・プラットホームを生成する段階と、コンポーネントの組み合わせのために、仮想ソフトウェア・プラットホームに備わった設定変数の設定値を変更する段階と、変更された設定変数に基づいた仮想ソフトウェア・プラットホームの実行結果によって、ソフトウェア・プラットホームの整合性を検証する段階と、を含み、当該ソフトウェア製品の正常な組み合わせ構成が可能であるか否かを先行的に検証することによって、テストコストと人力節減とを可能にする。
公开号:JP2011510418A
申请号:JP2010544215
申请日:2008-10-21
公开日:2011-03-31
发明作者:クォン，ジャ−グン；ソン，キョン−ホ
申请人:サムスン エレクトロニクス カンパニー リミテッド；
IPC主号:G06F9-44

专利说明:

[0001] 本発明は、コンポーネント・モデル基盤の仮想ソフトウェア・プラットホームを生成する方法及びこれを利用したソフトウェア・プラットホーム・アーキテクチャの検証方法に係り、さらに具体的には、コンポーネント・モデルを基に開発されるソフトウェアのプラットホーム・アーキテクチャを検証するために、直接的なコード内部具現段階に先立ち、仮想プラットホーム生成し、これを介してコンポーネント・モデル設計情報の無欠性及び信頼性を点検できる方法及び装置に関する。]
背景技術

[0002] ソフトウェア開発において、設計（design）段階は、具現（implementation）段階でなされる細部機能を把握し、多様な構成品が適切な方式で相互連動される構造をあらかじめ確認することによって、迅速であってエラーのない開発がなされるための一助とするための手続きである。ソフトウェアの規模が膨大になり、かつ複雑になるほど、かような設計段階で自動化されたシステムを介して、迅速性と正確性とを確保する必要性が高まっている。]
[0003] ＣＥ（consumer electronics）ソフトウェアのような埋め込み型（embedded）ソフトウェア分野では、機能の融合並びに複合及び新規機能の結合が頻繁に発生し、また市場の流れによって、迅速な市場出荷が要求され、かつ大規模量産体制が必要であるというような状況が発生するので、ソフトウェアの設計と具現との小さなエラーまでも正確に検出されて修正されねばならない。特に、具現が完了した後での事後テストでは、コストが急激に増大するので、最近のテスト概念は、要求事項分析及び設計段階での事前検証を介して、以後段階でのエラー発生を最小化するための方向に進んでいる。]
[0004] ＣＥソフトウェア開発において、再使用性（reusability）と可変性（variability）との管理を基に、多品種開発を効果的に支援するためのＳＰＬ（software product line）体制は、プラットホーム自体に対する検証と、設計情報に基づいた具現との自動化を遂行することができる方法を必要とする。]
[0005] 一般的に、ソフトウェアは、要求事項分析、設計、具現、テスト、配布の順序を経つつ、１つの完成品として開発される。設計に符合するように具現されているか否かということは、テスト段階で、ＴＣ（test case）作成を介して確認する。]
[0006] ソフトウェア開発において、最終段階で認識されるテスト段階で、従来には、一般的に各単位機能に対するユニットテスト（unit test）、全体システムのあらゆる単位機能を連動させた統合テスト（integration test）、性能及び非機能的項目に対するシステムテスト（system test）などの範疇に大きく区分されて進められる。]
[0007] すなわち、具現開発が完了したソフトウェアコードに対するテストのために、ソフトウェアコードに対するユニットテスト、統合テスト、システムテストなどの段階を進めつつエラーを修正し、さらにこれをコードに反映する。これにより、漸進的に安定化したソフトウェア製品として発展していくことになる。]
[0008] 最近では、ソフトウェアの規模が膨大になりつつ、既存の開発プロセスによるテスト方法の運用上で限界点を認識し、これをさらに効果的に行うための技術と方法とが研究されている。それらのうち、ＴＤＤ（test driven development）は、開発プロセス上のあらゆる領域にわたってテストを行うことによって、後半部に集中するテスト及び修正のための莫大なコスト発生を事前に除去するところに焦点を合わせた方法である。かような従来技術は、いずれも具現コードに対するテストに焦点を合わせている。]
[0009] 一方、多様な品種のソフトウェア製品（software product）を開発する場合には、共通のプラットホームに基づいて、特徴的な付加機能を具現する様相を示す。かようなソフトウェアの品質評価において、主要要素は、プラットホーム自らの安定性と共に、新しい機能の信頼性とも関連する。しかし、ＣＥソフトウェア開発において、従来技術の限界点は、多品種ソフトウェア製品が統合されたプラットホームに対して精巧な設計の検証がなされ難いのである。]
[0010] ソフトウェア開発でプラットホームは、個別的に各ソフトウェア製品自体だけの構造を記述するのではなく、基盤プラットホームとあらゆる可変要素とを統合する構造を表現できなければならない。このためには、可変性（variability）、コンポーネント（component）、依存性（dependency）及び設定（configuration）のような概念が効果的に組み合わされるコンポーネント・モデルが必要であり、かようなコンポーネント・モデルを基にして、具現すると共にプラットホームの設計構造に対する検証がなされなければならない。]
発明が解決しようとする課題

[0011] 本発明は、前記のような問題点を解決するために考案されたものであり、本発明がなそうとする技術的課題は、ソフトウェア開発において、体系的なコンポーネント・モデルを介して、ソフトウェア・プラットホーム・アーキテクチャから具現自動化を行い、設計と具現との整合性検証を支援するための方法及び装置を提供することである。]
課題を解決するための手段

[0012] 前記技術的課題は、本発明によって、コンポーネント・モデル基盤の仮想ソフトウェア・プラットホームを生成する方法において、ソフトウェア・プラットホームの設計情報によって、少なくとも一つ以上のコンポーネントの機能を記述するテンプレートコードを生成する段階と、ソフトウェア種類による設定変数が備わり、前記生成されたテンプレートコードのビルドを行うビルドスクリプトを生成する段階と、を含むことを特徴とする生成方法によって解決される。]
[0013] 前記テンプレートコードを生成する段階は、前記コンポーネントのうち、上位コンポーネント及び下位コンポーネントの包含関係を示すディレクトリ構造を生成する段階と、前記コンポーネントが要請する他のコンポーネントのインターフェースを示す依存関係を示す依存性要素を反映する段階と、前記設定変数によって前記包含または依存の関係にある複数個の前記コンポーネントを選択する可変性要素を反映する段階と、をさらに含むことが望ましい。]
[0014] 前記ビルドスクリプトを生成する段階は、前記ソフトウェアの種類を選択できるタイプ変数を定義する段階と、前記タイプ変数に連動された下位設定変数を記述する段階と、前記コンポーネントに対する設定変数間のマッピング関係によって設定値を指定する段階と、前記コンポーネントそれぞれのソースコードの経路情報を設定する段階と、をさらに含むことが望ましい。]
[0015] 前記ビルドスクリプトを生成する段階は、前記可変性要素を反映するように、前記ビルドスクリプト内に条件文形式のコードを追加することが望ましい。]
[0016] 前記可変性要素は、所定のコンポーネントを前記ビルドスクリプトの経路から除外させるオプション可変性、または前記設定変数の設定値によって所定のコンポーネントを選択するスイッチ可変性を含むことが望ましい。]
[0017] 前記ビルドスクリプトを生成する段階は、前記コンポーネントが複合（composite）コンポーネントである場合、下位コンポーネントに対するビルドスクリプトを再帰的に呼び出すように構成されたり、基本（primitive）コンポーネントである場合、自体のソースコードに係わるビルドプロセスを記述するように構成されることが望ましい。]
[0018] 一方、本発明の他の分野による技術的課題は、コンポーネント・モデル基盤のソフトウェア・プラットホーム・アーキテクチャの検証方法において、ソフトウェア・プラットホームの設計情報によって、少なくとも一つ以上のコンポーネントの機能を記述するテンプレートコード及びソフトウェア種類による設定変数が備わり、前記生成されたテンプレートコードのビルドを行うビルドスクリプトを具備する仮想ソフトウェア・プラットホームを生成する段階と、前記コンポーネントの組み合わせのために、前記仮想ソフトウェア・プラットホームに備わった設定変数の設定値を変更する段階と、前記変更された設定変数に基づいた前記仮想ソフトウェア・プラットホームの実行結果によって、前記ソフトウェア・プラットホームの整合性を検証する段階と、を含むことを特徴とする検証方法によって解決される。]
[0019] 前記設定変数の設定値を変更する段階は、前記コンポーネントに備わった可変性要素を設定する段階と、前記設定によって、前記仮想ソフトウェア・プラットホームをビルドする段階と、をさらに含むことが望ましい。]
[0020] 前記検証する段階は、前記ソフトウェア・プラットホームの設計情報からの獲得された呼び出しグラフ及び前記実行による関数呼び出しグラフを比較する段階と、前記比較結果に基づいて、前記ソフトウェア・プラットホームの依存性または無欠性を判断する段階と、をさらに含むことが望ましい。]
[0021] 前記検証する段階は、前記ソフトウェアの製品明細（product specification）の内容と、前記実行による前記コンポーネントのディレクトリ構成とを比較する段階と、前記比較結果に基づいて、前記変更された設定値によるソフトウェアの製品に対する前記設計情報を検査する段階と、をさらに含むことが望ましい。]
[0022] 前記コンポーネント・モデルの構成要素であるコンポーネント、インターフェース、連結、可変性のうち、少なくとも一つ以上の構成要素に係わる目録を管理する段階をさらに含むことが望ましい。]
[0023] 前記コンポーネント・モデルの構成要素に係わる目録を管理する段階は、前記コンポーネントに備わった可変性要素に対応する変数を定義するための言語構文を処理する段階をさらに含むことが望ましい。]
[0024] 一方、本発明のさらに他の分野による技術的課題は、コンポーネント・モデル基盤の仮想ソフトウェア・プラットホームを生成する装置において、ソフトウェア・プラットホームの設計情報によって、少なくとも一つ以上のコンポーネントの機能を記述するテンプレートコードを生成するコード生成部と、ソフトウェア種類による設定変数が備わり、前記生成されたテンプレートコードのビルドを行うビルドスクリプトを生成するビルドスクリプト生成部と、を含むことを特徴とする生成装置によっても解決される。]
[0025] 一方、本発明のさらに他の分野による技術的課題は、コンポーネント・モデル基盤のソフトウェア・プラットホーム・アーキテクチャの検証装置において、ソフトウェア・プラットホームの設計情報によって、少なくとも一つ以上のコンポーネントの機能を記述するテンプレートコード及びソフトウェア種類による設定変数が備わり、前記生成されたテンプレートコードのビルドを行うビルドスクリプトを具備する仮想ソフトウェア・プラットホームを生成する仮想プラットホーム生成部と、前記コンポーネントの組み合わせのために、前記仮想ソフトウェア・プラットホームに備わった設定変数の設定値を変更する仮想プラットホーム設定部と、前記変更された設定変数に基づいた前記仮想ソフトウェア・プラットホームの実行結果によって、前記ソフトウェア・プラットホームの整合性を検証するアーキテクチャ検証管理部と、を含むことを特徴とする検証装置によっても解決される。]
[0026] 前記コンポーネント・モデルの構成要素であるコンポーネント、インターフェース、連結、可変性のうち、少なくとも一つ以上の構成要素に係わる目録を管理するコンポーネント・モデル管理部をさらに含むことが望ましく、前記コンポーネント・モデル管理部は、前記コンポーネントに備わった可変性要素に対応する変数を定義するための言語構文を処理するコンポーネント言語記述子をさらに含むことが望ましい。]
[0027] さらに本発明は、コンポーネント・モデル基盤の仮想ソフトウェア・プラットホームを生成する方法及びこれを利用したソフトウェア・プラットホーム・アーキテクチャの検証方法を具現するためのプログラムが記録されたコンピュータで読取り可能な記録媒体を含む。]
[0028] さらに本発明において、ソフトウェア・プラットホーム・アーキテクチャの検証システムにおいて、前記検証システムは、コンポーネント・モデル基盤の仮想ソフトウェア・プラットホームを生成する装置と、コンポーネント・モデル基盤のソフトウェア・プラットホーム・アーキテクチャの検証装置と、を含み、前記コンポーネント・モデル基盤の仮想ソフトウェア・プラットホームを生成する装置は、ソフトウェア・プラットホームの受信された設計情報によって、ソフトウェアの少なくとも一つ以上のコンポーネントの機能を記述するテンプレートコードを生成するコード生成部と、前記ソフトウェアの種類による設定変数が備わり、前記生成されたテンプレートコードのビルドを行うビルドスクリプトを生成するビルドスクリプト生成部と、を含み、前記コンポーネント・モデル基盤のソフトウェア・プラットホーム・アーキテクチャの検証装置は、前記コンポーネントの組み合わせのために、前記仮想ソフトウェア・プラットホームに備わった設定変数の設定値を変更する仮想プラットホーム設定部と、前記変更された設定変数に基づいた前記仮想ソフトウェア・プラットホームの実行結果によって、前記ソフトウェア・プラットホームの整合性を検証するアーキテクチャ検証管理部と、を含むことを特徴とする検証システムである。]
[0029] さらに本発明において、コンポーネント・モデル基盤のソフトウェア・プラットホーム・アーキテクチャの検証装置において、前記検証装置は、ソフトウェア・プラットホーム・アーキテクチャの設計情報によって、ソフトウェアの少なくとも一つ以上のコンポーネントの機能を記述するテンプレートコード、及びソフトウェア種類による設定変数が備わり、前記テンプレートコードのビルドを行うビルドスクリプトを具備する仮想ソフトウェア・プラットホームを使用し、前記コンポーネントの組み合わせのために、前記仮想ソフトウェア・プラットホームに提供された設定変数の設定値を変更する仮想プラットホーム設定部と、前記変更された設定変数に基づいた前記仮想ソフトウェア・プラットホームの実行結果によって、前記ソフトウェア・プラットホームの整合性を検証するアーキテクチャ検証管理部と、を含むことを特徴とする検証装置である。]
発明の効果

[0030] 本発明によるソフトウェア・プラットホーム・アーキテクチャの検証方法及び装置によれば、次のような効果が認められる。]
[0031] 第一に、本発明は、多様なソフトウェア製品を統合するソフトウェア・プラットホーム設計に対する検証において、コンポーネント・モデルが含んでいる設計情報から仮想プラットホームの生成と検証とを自動化できる技術を提案している。従って、従来のソフトウェア検証がソフトウェア・プラットホーム・アーキテクチャに対してなされず、個別コードに係わる具現後のテストに限定されていた制約事項を克服できる。]
[0032] 第二に、ソフトウェア・プラットホームは、膨大なソースコード、ビルドスクリプト、ライブラリの集合体であり、要素の組み合わせによって、特定要求に符合するソフトウェア製品の開発を可能にする方式がコンポーネント・モデルの目的である。コンポーネント・モデルによってソフトウェア製品の構成情報を記述し、これから当該ソフトウェア製品の正常な組み合わせ構成が可能であるか否かを先行的に検証することによって、テストコストと人力節減とを可能にする。]
[0033] 第三に、ソフトウェア・プラットホーム設計情報であるコンポーネント・モデルから仮想プラットホームが生成され、仮想プラットホームは、実際の具現に必要なあらゆる土台を備えており、ソフトウェア具現における同期化と正確性とを極大化できる。]
[0034] 第四に、主要ソフトウェア設計ツールと連繋し、既存のＵＭＬ（unified modeling language）基盤のソフトウェア開発プロセス上で管理し難かったソフトウェア・プラットホームの検証機能を確保することができる。]
図面の簡単な説明

[0035] 本発明の一実施形態による、ソフトウェア・プラットホーム・アーキテクチャの検証装置の構成モジュールを示す図である。
本発明の他の実施形態による、コンポーネント・モデル基盤の仮想ソフトウェア・プラットホームを生成する方法について説明するためのフローチャートである。
本発明の他の実施形態による、コンポーネント・モデル基盤のソフトウェア・プラットホーム・アーキテクチャの検証方法について説明するためのフローチャートである。
仮想ソフトウェア・プラットホーム生成過程で具現される物理的ディレクトリ構造を示す図である。
仮想ソフトウェア・プラットホーム生成過程で具現されるＢＬＣ（build-level component）適用例を示す図である。
仮想ソフトウェア・プラットホーム生成過程で具現されるテンプレートコードを示す図面である。
仮想ソフトウェア・プラットホーム生成過程で具現されるコンポーネント依存性を示す図である。
仮想ソフトウェア・プラットホーム生成過程で具現されるオプション可変性を示す図である。
仮想ソフトウェア・プラットホーム生成過程で具現されるスイッチ可変性を示す図である。
仮想ソフトウェア・プラットホーム生成過程で具現されるビルドスクリプト生成構造を示す図である。
ソフトウェア製品選択のためのビルドスクリプトであるmakefile.config_decision構成の実施形態を示す図面である。
ソフトウェア製品設定のためのビルトスクリプトであるmakefile.config_option構成の実施形態を示す図である。
設定変数のマッピングのためのビルドスクリプトであるmakefile.config_mapping構成の実施形態を示す図である。
コンポーネントビルド経路のためのビルドスクリプトであるmakefile.config_path構成の実施形態を示す図である。
複合コンポーネントmakefile構成の実施形態を示す図である。
基本コンポーネントのmakefile構成の実施形態を示す図である。
呼び出しグラフ無欠性確認コードの実施形態を示す図である。
呼び出しグラフ無欠性確認テーブルの実施形態を示す図である。]
実施例

[0036] 本発明並びに本発明の動作上の利点、及び本発明の実施によって達成される目的を十分に理解するためには、本発明の望ましい実施形態を例示する添付図面及び図面に記載された内容を参照せねばならない。]
[0037] 以下、添付された図面を参照しつつ、本発明の望ましい実施形態について詳細に説明する。]
[0038] 本発明は、コンポーネント・モデルを基に開発されるＣＥ（consumer electronics）ソフトウェアのプラットホーム・アーキテクチャを、ＳＰＬ（software product line）側面で検証するために、直接的なコードの内部具現段階に先立ち、仮想プラットホーム（virtual platform）の生成（generation）及び設定（configuration）を介して、コンポーネント・モデルの設計情報についての無欠性及び信頼性を点検できる方法及び装置を提供する。]
[0039] すなわち、再使用性とＳＰＬ運営とのためのコンポーネント・モデル基盤、すなわち、ＣＢＳＥ（component-based software engineering）を基盤とするＣＥソフトウェア開発において、ソフトウェア・プラットホーム・アーキテクチャから具現自動化を行い、設計と具現との整合性検証及び管理を支援するための解決方案を提示する。]
[0040] 図１は、本発明の一実施形態による、ソフトウェア・プラットホーム・アーキテクチャの検証装置１００の構成モジュールを示す。] 図１
[0041] ソフトウェア・プラットホーム・アーキテクチャの無欠性（integrity）と信頼性（reliability）との検証のために、本発明は基本的に、仮想プラットホーム生成部１２０、仮想プラットホーム設定部１３０、アーキテクチャ検証管理部１４０を含み、コンポーネント・モデル管理部１１０をさらに含むことができる。ここで、仮想プラットホーム生成部１２０は、ソフトウェア・プラットホームの設計情報によって、少なくとも一つ以上のコンポーネントの機能を記述するテンプレートコード及びソフトウェア種類による設定変数が備わり、前記生成されたテンプレートコードのビルドを行うビルドスクリプトを具備する仮想ソフトウェア・プラットホームを生成するモジュールであり、仮想プラットホーム設定部１３０は、コンポーネントの組み合わせのために、前記仮想ソフトウェア・プラットホームに備わった設定変数の設定値を変更するモジュールであり、アーキテクチャ検証管理部１４０は、変更された設定変数に基づいた仮想ソフトウェア・プラットホームの実行結果によって、ソフトウェア・プラットホームの整合性を検証するモジュールであり、コンポーネント・モデル管理部１１０は、コンポーネント・モデルの構成要素であるコンポーネント、インターフェース、連結、可変性のうち、少なくとも一つ以上の構成要素に係わる目録を管理するモジュールである。]
[0042] 前記各構成モジュールについての具体的な説明及び下位モジュールについての説明に先立ち、本明細書で使われる用語の概念について説明すれば、次の通りである。]
[0043] 設定変数（configuration variable）：コンポーネント・モデルとして記述されたソフトウェア・プラットホーム構成において、可変性（variability）を表現するために使われた変数である。]
[0044] 可変性ポイント（variability point）：ソフトウェア製品を構成するにあたって、可変的な特性または当該特性が存在する部分をいう。]
[0045] ソフトウェア製品ライン（ＳＰＬ：software product line）：ソフトウェア製品は基本的に、共通要素と可変要素とをいずれも含むソフトウェア・プラットホームから、開発要求事項によって選別的に組み合わせられた要素によって構成されるが、それら多様なソフトウェア製品は共通要素を有しているので、所定の製品群（product family）を構成することになる。ＳＰＬは、このように、ソフトウェア・プラットホームから多様な製品を開発するためのソフトウェア要素管理及び構成体系を意味する。]
[0046] ソフトウェア・コンポーネント（software component）：ソフトウェア製品は、数多くのソースコード（source code）、ビルドスクリプト（build script）、ライブラリ（library）などから構成される。ソフトウェア・コンポーネントは、物理的なコードファイル（code file）やスクリプト（script）またはディレクトリ（directory）の単位自体を示すものではなく、機能的側面で分割された単位である。従って、いくつかのディレクトリが１つのコンポーネントになることもあり、１つのソースコードが１つのコンポーネントとして規定されることも可能である。]
[0047] 基本／複合コンポーネント（primitive/composite component）：単位コンポーネントを基本コンポーネント（primitive component）といい、それら基本コンポーネントを組み合わせて、複合コンポーネント（composite component）を構成できる。]
[0048] 提供／要請インターフェース（provide/require interface）：コンポーネント間の連結関係を記述するにおいて、特定コンポーネントが供給する機能は、提供インターフェース（provide interface）として表現し、特定コンポーネントが異なったコンポーネントの機能を使用する場合は、要請インターフェース（require interface）として表現する。以下、コンポーネント・モデルを示す図面において、提供インターフェースである場合には、「ｉｐ（interface provided）」、要請インターフェースである場合には、「ｉｒ（interface required）」という接頭辞（prefix）を使用して表示する。]
[0049] ルート複合コンポーネント（root composite component）：ソフトウェア製品自体は、内部に基本コンポーネントとサブ複合（sub composite）コンポーネントとを有する最も大きい規模の最上位複合コンポーネントであるといえる。これをルート複合コンポーネントと称する。]
[0050] ＦＬＣ（functional-level component）：コンポーネント・モデル設計に必要な論理的な単位であり、全体システムを構成する各基本コンポーネントと複合コンポーネントは、いずれもＦＬＣに属する。]
[0051] ＢＬＣ（build-level component）：ＦＬＣの実際具現体としてのコンポーネント単位であり、基本コンポーネント（primitive component）に対してのみ対応関係を有する。コンポーネントの組み合わせにおいて、１つのＦＬＣは、自体の機能を具現した少なくとも一つ以上のＢＬＣとマッピング（mapping）される。]
[0052] ＣＤＬ（component description language）：ＦＬＣコンポーネント構成を記述するための規定である。基本コンポーネントの場合には、提供インターフェースまたは要請インターフェース情報だけで表現されるが、複合コンポーネントの場合には、下位コンポーネントの相互連結関係及び設定変数の情報などがさらに表現される。]
[0053] ＩＤＬ（interface description language）：あらゆる基本コンポーネントが供給する提供インターフェースは、実際にいかなる機能を含むか詳細内訳を記述せねばならず、それら情報がＩＤＬに表現される。]
[0054] ＢＣＤＬ（build-level component description language）：ＦＬＣ構成がＣＤＬによって表現されるならば、各コンポーネントの実際の具現体であるＢＬＣの情報は、ＢＣＤＬを介して表現される。ＢＣＤＬは、特定コンポーネントの具現のためのソース、ライブラリ、ビルド情報などを含む。]
[0055] 図１を参照するに、コンポーネント・モデル管理部１１０は、ソフトウェア・プラットホーム・アーキテクチャ設計にあたって、コンポーネント・モデルを基に構成されるあらゆる要素を管理するモジュールである。コンポーネント・モデル管理部１１０は、コンポーネント・ハンドラ（component handler）１１１、インターフェース・ハンドラ（interface handler）１１２、連結ハンドラ（connection handler）１１３、可変性ハンドラ（variability handler）１１４と連繋し、コンポーネント・モデル要素であるコンポーネント、インターフェース、連結、可変性の各要素の追加、変更、除去などの目録を管理し、プラットホーム・アーキテクチャ全体構成情報を管理する。] 図１
[0056] コンポーネント・ハンドラ１１１は、コンポーネント・モデル管理部１１０を介して管理されるコンポーネント・モデルの構成要素情報のうち、コンポーネント要素の目録及び特性情報を管理するモジュールである。]
[0057] ソフトウェア・プラットホーム内の各コンポーネントは、基本的に、基本コンポーネント及び複合コンポーネントから構成され、複合コンポーネントは、階層的なディレクトリ構造と共に、サブシステム構成を反映することになる。コンポーネント・ハンドラ１１１は、それらコンポーネント間の連動情報を把握して管理する。]
[0058] インターフェース・ハンドラ１１２は、コンポーネント・モデル管理部１１０を介して管理されるコンポーネント・モデルの構成要素情報のうち、インターフェース要素の目録及び特性情報を管理するモジュールである。]
[0059] インターフェースは、コンポーネントが提供する機能と必要とする機能とを関数集合（function set）として記述する要素であり、コンポーネント間の相互作用のための道具となる。インターフェース・ハンドラ１１２は、インターフェース要素の目録及びコンポーネントとインターフェースとの連結情報を管理する。]
[0060] 連結ハンドラ１１３は、コンポーネント・モデル管理部１１０を介して管理されるコンポーネント・モデルの構成要素情報のうち、コンポーネント間の依存関係を表現する連結要素の目録及び特性情報を管理するモジュールである。]
[0061] 連結は、インターフェース間の連結自体を意味するものであり、コンポーネント・モデル内で実際の連動関係の存在を示す要素である。連結ハンドラ１１３は、連結要素の目録及び情報を管理する。]
[0062] 可変性ハンドラ１１４は、コンポーネント・モデル管理部１１０を介して管理されるコンポーネント・モデルの構成要素情報のうち、可変性要素の目録及び特性情報を管理するモジュールである。]
[0063] 可変性は、ソフトウェア・プラットホームの共用部と可変部とを区分できる要素であり、可変性が設定されたコンポーネントを多様に選択することによって、ソフトウェア・プラットホーム設計情報内にあらゆるコンポーネントが統合されうる基盤を提供する。可変性ハンドラ１１４は、可変性要素の目録及び各可変性の設定条件情報を管理する。]
[0064] コンポーネント言語記述子（component language descriptor）１１５は、コンポーネント・モデルを記述するための言語処理を担当するモジュールである。基本的に、基本コンポーネント及び複合コンポーネントの構成情報を含み、可変性ポイントに対応する変数を定義する構文形式を支援する。可変性ポイントが含まれた複合コンポーネントにおいて表現される構文ブロックとして、具体的に、「ｃｏｎｔａｉｎｓ」は、複合コンポーネントが内部に含む下位コンポーネント目録を示し、「ｐｒｏｖｉｄｅｓ」は、コンポーネントの提供インターフェースであり、複合コンポーネントである場合には、下位コンポーネントから提供される提供インターフェースの目録を示し、「ｒｅｑｕｉｒｅｓ」は、コンポーネントの要請インターフェースであり、複合コンポーネントである場合には、下位コンポーネントからの要請インターフェースの目録を示し、「ｃｏｎｎｅｃｔｓ」は、提供／要請インターフェース間の連結関係を記述し、「ｃｏｎｆｉｇｕｒａｔｉｏｎ−ｖａｒｉａｂｌｅｓ」は、可変性ポイントに対応する変数と値との目録を記述する。]
[0065] コンポーネント言語記述子１１５は、ＣＤＬ（component description language）、ＩＤＬ（interface description language）、ＢＣＤＬ（build-level component description language）、ＰＣＬ（product configuration language）などの構文処理及び生成を担当する。]
[0066] 仮想プラットホーム生成部１２０は、ソフトウェア・プラットホーム・アーキテクチャ設計の信頼性を検証するための仮想プラットホーム生成を担当するモジュールである。コンポーネント・モデルとして構成されたソフトウェア・プラットホームの設計構造によって、コンポーネント依存性と可変性との設定などの要素があらゆる設定経路（configuration path）を満足できるか否かを検証する。このために、基本的に、コンポーネント別ソースコード及びビルドスクリプトを生成し、可変性要素の設定による構成を準備する。]
[0067] 仮想プラットホーム生成部１２０は、必要な構成項目を把握し、コード生成部１２１やビルドスクリプト生成部１２２のような連動モジュールに生成作業を要請する機能を行う。仮想プラットホーム生成部１２０は、アーキテクチャ検証管理部１４０からのプラットホーム検証要求によって動作される。]
[0068] コード生成部１２１は、仮想プラットホーム生成部１２０と連動し、コンポーネント・モデルに対応する実際に物理的なソースコードの構成と生成とを担当するモジュールである。]
[0069] コード生成部１２１は、図４から図９までの各作業と関連し、実際のディレクトリ生成、ソースコード内部の条件文（conditional statement）処理、コンポーネント依存性によるヘッダ包含（header inclusion）、関数呼び出し無欠性確認（function call integrity check）コード追加などの機能を行う。] 図４ 図９
[0070] ビルドスクリプト生成部１２２は、仮想プラットホーム生成部１２０と連動し、コンポーネント・モデルに対応する物理的なビルドスクリプトの構成と生成とを担当するモジュールである。]
[0071] ビルドスクリプト生成部１２２は、図１０から図１６の各作業と関連し、コンポーネント別のビルドスクリプトの生成及びビルドスクリプト内部の条件文処理などの機能を行う。ビルドスクリプト生成は、コンポーネント・モデルの可変性構成形態を反映し、階層的構成を有する。] 図１０ 図１６
[0072] 仮想プラットホーム設定部１３０は、コンポーネント・モデルの可変性を特定状態に設定し、このときのプラットホーム構成が、設計によって正常に実行されるか否かを確認するための設定とビルド（build）との機能を担当する。]
[0073] 設計情報の検証側面で、あらゆる内部具現が完了した時点のテストとは異なる概念であり、可変性によって組み合わせ構成されたコンポーネント・ソースコードとビルドスクリプトとがエラーを発生させないか否かを確認することによって、検証を行うのである。]
[0074] 仮想プラットホーム設定部１３０は、アーキテクチャ検証管理部１４０からのプラットホーム検証要求によって、仮想プラットホーム生成部１２０を介した仮想プラットホームが生成された後に動作することになる。]
[0075] アーキテクチャ検証管理部１４０は、ソフトウェア製品目録別に、コンポーネント・モデルに含まれた設定変数の設定に対し、それぞれ設計に符合する正常なコンポーネント組み合わせ及びビルドが可能であるか否かを確認し、プラットホーム検証を担当する。]
[0076] 仮想プラットホーム生成部１２０と仮想プラットホーム設定部１３０とを介して、仮想プラットホームの生成と設定とを行わせ、その結果を分析判断する。]
[0077] 依存性／無欠性確認部（dependency integrity checker）１４１は、ソースコード間の関数呼び出し関係が、設計通りなされている否かを判断するが、設計情報からの呼び出しグラフ及び実際の呼び出しによって記録された呼び出しグラフを比較することによって判断する。]
[0078] 仮想製品検証部１４２は、仮想プラットホームの設定とフィールドとが遂行されれば、各製品明細（specification）を記述したＰＣＬ設定によって設計した通り、適切なコンポーネントを含んでいるか否かということと、設定変数の設定が正常になされているか否かとを確認する。]
[0079] 図２は、本発明の他の実施形態による、コンポーネント・モデル基盤の仮想ソフトウェア・プラットホームを生成する方法について説明するためのフローチャートである。] 図２
[0080] 本発明の実施形態による、仮想ソフトウェア・プラットホームを生成する方法は、ソフトウェア・プラットホームの設計情報によって、少なくとも一つ以上のコンポーネントの機能を記述するテンプレートコードを生成する段階（２１０）と、ソフトウェア種類による設定変数が備わり、前記生成されたテンプレートコードのビルドを行うビルドスクリプトを生成する段階（２２０）とを含む。各段階についての説明は、以下の図４ないし図１６を参照しつつ、詳細に説明する。] 図１６ 図４
[0081] 図３は、本発明の他の実施形態による、コンポーネント・モデル基盤のソフトウェア・プラットホーム・アーキテクチャの検証方法について説明するためのフローチャートである。] 図３
[0082] 本発明の実施形態による、ソフトウェア・プラットホーム・アーキテクチャの検証方法は、ソフトウェア・プラットホームの設計情報によって、少なくとも一つ以上のコンポーネントの機能を記述するテンプレートコード、及びソフトウェア種類による設定変数が備わり、前記生成されたテンプレートコードのビルドを行うビルドスクリプトを具備する仮想ソフトウェア・プラットホームを生成する段階（３１０）と、コンポーネントの組み合わせのために、仮想ソフトウェア・プラットホームに備わった設定変数の設定値を変更する段階（３２０）と、変更された設定変数に基づいた前記仮想ソフトウェア・プラットホームの実行結果によって、ソフトウェア・プラットホームの整合性を検証する段階（３３０）とを含む。]
[0083] さらに、前記検証方法は、コンポーネント・モデルの構成要素であるコンポーネント、インターフェース、連結、可変性のうち、少なくとも一つ以上の構成要素に係わる目録を管理する段階をさらに含むことができる。]
[0084] 本発明の実施形態であるソフトウェア・プラットホーム・アーキテクチャ検証とは、ソフトウェア製品の設計情報がいずれも含まれた統合プラットホームの構成情報に対する信頼性を確認することを意味する。ここで信頼性とは、統合されたプラットホームの構成から、個別製品の引き出しが可能であることを指す。]
[0085] ソフトウェア・プラットホームの設計構成情報は、当該プラットホームを基盤とするソフトウェア製品の組み合わせ（composition）のための設定要素、及び前記設定情報の表現のための可変性要素によって記述され、コンポーネント・モデルは、それらの要素を体系的に連動管理できる基盤になる。]
[0086] 設計情報から具現を進めるトップダウン（top-down）プロセスにおいて、ソフトウェア・プラットホームの設定が行われ、各ソフトウェア製品に適したコンポーネント組み合わせがなされているか否かを確認する作業は、コンポーネント自体の内部具現より先行されねばならない。設計情報だけを利用して、まだ生成されていないフトウェア・プラットホームを検証しなければならない状況で、仮想（virtual）ソフトウェア・プラットホームの必要性が高まっている。]
[0087] ソフトウェア・プラットホーム・アーキテクチャ検証に伴う手続きには、仮想プラットホームを生成する段階と、仮想プラットホームを設定する段階とがある。仮想プラットホームを生成する段階は、アーキテクチャ設計情報に基いて、コンポーネント・モデルの仮想的な骨格構造を生成する段階をいい、仮想プラットホームを設定する段階は、アーキテクチャ設計情報に基いて、ソフトウェア製品組み合わせを構成する段階をいう。]
[0088] 本発明を構成する各モジュール間の相互作用を介して、ソフトウェア・プラットホーム・アーキテクチャの設計構成情報であるコンポーネント・モデルの検証を行う全体動作の手続きは、次の通りである。]
[0089] １）コンポーネント・モデル管理部（component model manager）１１０は、ソフトウェア・プラットホーム設計を担当するユーザによって、コンポーネント・モデル編集及び変動内訳を管理し、コンポーネント言語記述子（component language descriptor）１１５を介して、変更されたコンポーネント・モデルを記述する。]
[0090] ２）コンポーネント・モデル管理部１１０は、コンポーネント・モデルに含まれた構成要素それぞれの情報を独立して管理できるように、コンポーネント・ハンドラ１１１、インターフェース・ハンドラ１１２、連結ハンドラ１１３、可変性ハンドラ１１４を介して、構成要素別目録及び細部情報を分析する。]
[0091] ３）アーキテクチャ検証管理部（architecture validation manager）１４０を介して、コンポーネント・モデル基盤のソフトウェア・プラットホーム・アーキテクチャ検証を行う。アーキテクチャ検証管理部１４０は、仮想プラットホーム生成部（virtual platform generator）１２０に作業を要請する。]
[0092] ４）仮想プラットホーム生成部１２０を介して、コンポーネント・モデルに基づいたテンプレートコード（template code）及びビルドスクリプト（build script）の生成作業がなされる。]
[0093] ５）仮想プラットホーム生成部１２０の要請によって、コード生成部（code generator）１２１は、階層構造によるディレクトリ及びソースコードの生成、可変性設定の反映、依存性設定の反映作業を行う。]
[0094] ６）仮想プラットホーム生成部１２０の要請によって、ビルドスクリプト生成部（build script generator）１２２は、可変性設定及び階層構造によるビルドスクリプトを生成する。生成されるビルドスクリプトには、全体プラットホーム設定のためのビルドスクリプトと、各コンポーネント別のビルドスクリプトとがいずれも含まれる。]
[0095] ７）仮想プラットホームの生成完了後には、アーキテクチャ検証管理部１４０を介して、仮想プラットホーム設定部（virtual platform configurator）１３０に、仮想プラットホームの設定及びソフトウェア製品生成検証を要請する。]
[0096] ８）仮想プラットホーム設定部１３０は、ビルドスクリプトのうち、Makefile.config_decisionに記述されたソフトウェア製品設定のための最上位（top-level）設定変数の設定値を変更し、ビルドを行う。]
[0097] ９）依存性／無欠性確認部（dependency integrity checker）１４１は、ビルド完了したソフトウェア製品の実行ファイルを呼び出し、テンプレート関数（template function）の呼び出しグラフ（call graph）が設計構成に符合するか否かを確認する。]
[0098] １０）仮想ソフトウェア・プラットホームのビルド遂行後、仮想製品検証部（virtual product verifier）１４２は、ソフトウェア製品の明細を定義したＰＣＬ記述内容と実際のディレクトリ構成とを比較する。]
[0099] １１）最終的に、アーキテクチャ検証管理部１４０は、依存性／無欠性確認部と仮想製品検証部との点検結果を基に、当該ソフトウェア・プラットホームの設計検証結果を判断する。]
[0100] 仮想ソフトウェア・プラットホーム生成過程は、ソフトウェア・プラットホーム・アーキテクチャ構成のためのコンポーネント・モデル設計がなされた後、アーキテクチャ検証管理部によって検証機能が要請されて実行される各段階を示すものであり、以下で各項目を細部について説明する。]
[0101] 図４は、仮想ソフトウェア・プラットホーム生成過程で具現される物理的ディレクトリ構造を示している。] 図４
[0102] コンポーネント間の物理的ディレクトリ構造４２０を生成する過程は、コンポーネント・モデル４１０として設計されたソフトウェア・プラットホーム構造によって、階層的な形態として、各コンポーネントの定義及びコンポーネントの経路と配置とを決定する手続きである。]
[0103] コンポーネント・モデルは、最上位複合コンポーネントであるルート複合コンポーネントを最上位ディレクトリとして設定し、その内部設定の階層構造によって、順次に下位コンポーネントに係わるディレクトリを生成することになる。最下位に置かれる各基本コンポーネントは、仮想プラットホーム生成時の条件設定によって、ヘッダファイル（header file）とソースファイル（source file）とのための別途下位ディレクトリを有することもできる。]
[0104] ここで、図４は、ソフトウェア・プラットホームとしての最上位複合コンポーネントＴ及び内部コンポーネント設定による、ディレクトリ構造を生成する例を示している。下位コンポーネントは、上位コンポーネントのディレクトリ内部に生成されて配され、このときに生成された相対経路（path）は、以後のＢＬＣ（build-level component）を定義するにおいて、参照情報として使われる。] 図４
[0105] 図５は、仮想ソフトウェア・プラットホーム生成過程で具現されるＢＬＣ適用例を示している。図５では、ＢＬＣ情報を記述するためのＢＣＤＬと、ファイルリスト（file list）文書の内部記述形式とを示している。コンポーネント組み合わせの側面で見るとき、ＢＬＣは、自体以外の相対経路が書き込まれていない基本形ＢＣＤＬ及びファイルリストをまず生成した後、ＢＬＣコンポーネント保存所（repository）に保存される（５１０）。その後、コンポーネント・モデル内に配されることによって相対経路が指定され、ＢＣＤＬとファイルリストは、相対経路を反映した形態に修正され、当該ソフトウェア・プラットホーム構造内での唯一の位置を付与されることになる（５２０）。これにより、新しいソフトウェア・プラットホームのためのコンポーネント・モデル設計時には、他の相対経路を反映したＢＣＤＬとファイルリストとが生成されうる。] 図５
[0106] 図６は、仮想ソフトウェア・プラットホーム生成過程で具現されるテンプレートコードを示している。] 図６
[0107] 各コンポーネントに対応するディレクトリ構造が生成されると同時に、各ディレクトリ内部には、当該コンポーネントの機能を具現するテンプレートコードの生成が自動的になされる。それらのコードは、コンポーネントの機能を定義したＩＤＬ（interface definition language）の関数集合（function
set）を記述する（６１０）。各コンポーネントのテンプレートコードは、ヘッダファイルとソースファイルとの対によって構成されるが（６２０）、基本的に、関数集合目録がヘッダファイルに羅列され、ソースファイル内には、各関数の具現のための空いている構文ブロックが羅列される。]
[0108] 図６は、Ａ１コンポーネントについてのテンプレートコードの生成例を示している。Ａ１コンポーネントは、Ｉ＿Ａ１インターフェースを提供しており、Ｉ＿Ａ１．ＩＤＬでＩ＿Ａ１インターフェースは、ｆｕｎｃ１＿Ａ１、ｆｕｎｃ２＿Ａ１、ｆｕｎｃ３＿Ａ１の関数集合を含むと定義されている。テンプレートコードのうちヘッダファイル（Ａ１．ｈ）は、インターフェース定義によって、３つの関数目録を含んでおり、ソースファイル（Ａ１．ｃｐｐ）は、実際内部の具現なしに、各関数に係わるブロックだけを含む。このとき、生成されたテンプレートファイル目録は、その後のＢＬＣを定義するにあたって、参照情報として使われる。] 図６
[0109] 図５を再び参照するに、ＢＬＣを記述するためのＢＣＤＬ及びファイルリストの内部に、当該ＢＬＣのためのヘッダファイルとソースファイルとの目録が含まれている。それらのファイル目録自体は、ディレクトリ構造の変化とは関係なしに常に一定に維持され、ディレクトリ構造を反映した相対経路のみがファイル目録に追加される。] 図５
[0110] 図７は、仮想ソフトウェア・プラットホーム生成過程で具現されるコンポーネント依存性を示している。] 図７
[0111] 提供インターフェース（ｉｐ）と要請インターフェース（ｉｒ）との連結として表現されるコンポーネント間の依存性の関係７１０は、実際のコードでは、ヘッダファイル参照及び関数呼び出しとして示されることになる。すなわち、特定コンポーネントの関数を使用する他のコンポーネントのソースコード内部には、対象コンポーネントのヘッダファイルに係わる参照と当該関数に係わる呼び出しとが含まれる（７２０）。]
[0112] 図７には、参照関係を有するコンポーネントのテンプレートコード内部を示している。Ａ２コンポーネントは、Ａ１コンポーネントが提供するＩ＿Ａ１インターフェースを要請しており、Ｂ１コンポーネントは、Ｉ＿Ａ２インターフェースを要請している。各コンポーネントのテンプレートコード内部には、参照対象コンポーネントのヘッダファイルを、「ｉｎｃｌｕｄｅ」構文として含む形態で記述される。] 図７
[0113] 図８は、仮想ソフトウェア・プラットホーム生成過程で具現されるオプション可変性（option variability）を示す。] 図８
[0114] 本発明が提案するコンポーネント・モデル基盤の仮想プラットホーム生成は、最終的に、テンプレートコードのビルドを介してエラー発生いかんを確認することによって、ソフトウェア・プラットホーム・アーキテクチャを検証するのである。このために、テンプレートコードのビルド作業を行うことができるビルドスクリプトの生成が自動的になされねばならない。]
[0115] コンポーネント・モデルで可変性は、「オプション（option）」と「スイッチ（switch）」との二種に区分できる。そのうちオプション可変性は、指定されたコンポーネントが設定変数の設定値によって、ソフトウェア製品のコンポーネント組み合わせに含まれないこともあることを意味する（８１０）。これは、ビルドスクリプトを介して、当該コンポーネントのソースコードに係わるビルド経路を除外させる方式で処理されるのである。かようなオプション可変性を反映するために、ビルドスクリプト内に、条件文（conditional statement）を含める（８２０）。]
[0116] 図８では、オプション設定されたコンポーネントＡ１とＢ２とに係わって、ビルドスクリプト内部で対象コンポーネントの経路が制御されるように、コンポーネント・モデルの設定変数を反映した例である。] 図８
[0117] 図９は、仮想ソフトウェア・プラットホーム生成過程で具現されるスイッチ可変性（switch variability）を示す。] 図９
[0118] スイッチ可変性は、２個以上のコンポーネントから提供されるインターフェースのうち、条件によって択一し、要請インターフェースと連結するための用途として使われる（９１０）。スイッチ可変性自体としては、選択されていないインターフェースとコンポーネントとを、コンポーネント組み合わせ構成から除外させない。すなわち、スイッチによって連結するコンポーネントは、いずれもコンポーネント組み合わせに含まれ、ただし設定変数の設定値によって、実際に利用されるインターフェースが変わるだけである。すなわち、前記説明したオプション可変性を別途に指定しない場合に、ビルドスクリプト経路から除外されないのである（９２０）。]
[0119] 図９は、スイッチ設定されたコンポーネントＡ１とＡ２とが、相互排他的にＢ１コンポーネントと連結されうる構成で、実際にＢ１が参照するヘッダファイルに係わるテンプレートコードを表現した例である。ｉｐＩ＿Ａ１とｉｒＩ＿Ａとのインターフェースは、互換性があり、ｉｐＩ＿Ａ２とｉｒＩ＿Ａとのインターフェースも、互換性があり、連結可能であるという前提に立つ。] 図９
[0120] 図１０は、仮想ソフトウェア・プラットホーム生成過程で具現されるビルドスクリプト生成構造を示す。] 図１０
[0121] 前述の通り、オプション可変性を反映させるために、ビルドスクリプト内に条件文を含めたのである。全体ビルドスクリプト生成の階層的構造は、図１０のようになされる。ソフトウェア・プラットホームに係わるコンポーネント・モデルでは、上位設定変数が下位設定変数とマッピング関係を介して設定作業を代行できる。各ソフトウェア製品に係わる設定変数設定及びＦＬＣ−ＢＬＣ間マッピング作業は、ＰＣＬ（product configuration language）で記述される。ＳＰＬ（software product line）側面で、ソフトウェア・プラットホームに係わるコンポーネント・モデルの上位設定変数は、ソフトウェア製品タイプまたはモデルタイプとして取扱うことができる。] 図１０
[0122] 以下、図１１から図１６でのように、ビルドスクリプトの生成は、コンポーネント・モデルの構造的な特性を反映させ、それぞれconfig_decision、config_option、config_mapping、config_path及び各コンポーネント別のビルドスクリプトで構成される。下の実施形態を介して、makefileに係わる詳細構成について説明する。Makefileとは、全体ビルドプロセスを始めるための出発地点であり、ビルド経路の最上位経路及びビルド結果物の位置情報を記述する。] 図１１ 図１６
[0123] makefile.config_decision：最上位設定変数の設定値を選択できる決定ポイント（decision point）の役割を担当する。]
[0124] makefile.config_option：最上位設定変数とマッピング関係にある設定変数のうち、直接的に製品の特性として分類された項目の設定値集合を記述する役割を担当する。]
[0125] makefile.config_mapping：コンポーネント・モデル内の他のあらゆる設定変数間のマッピング関係によって最下位設定変数の設定値を記述し、これと共に基本コンポーネントの組み合わせいかんを共に記述する役割を担当する。]
[0126] makefile.config_path：当該ソフトウェア・プラットホーム内のあらゆるコンポーネントに係わるソースコードの経路情報を記述する役割を担当する。]
[0127] Makefile：複合コンポーネントの場合、下位コンポーネントに係わるビルドスクリプト（makefile）を再帰的に呼び出す構成を有し、基本コンポーネントは、自体のソースコードに係わるビルドプロセスを記述するビルドスクリプト構成を有する。]
[0128] 以下、図１１ないし図１６で説明するが、前記各ビルドスクリプトは、図１０での参照番号１０１０ないし１０５０の順序で上位ビルドスクリプトを参照し、実行に必要な変数及び設定情報を把握できる。Makefileの場合は、「ｉｎｃｌｕｄｅ」構文を利用し、自体より先行するmakefileを参照する。] 図１０ 図１１ 図１６
[0129] 図１１は、ソフトウェア製品選択のためのビルドスクリプトであるmakefile.config_decision構成の実施形態を示している。] 図１１
[0130] 図１１は、ソフトウェア・プラットホームから特定ソフトウェア製品のためのコンポーネント組み合わせを遂行することができるように、当該製品タイプを選択して記述できるmakefile.config_decisionの構成を示している。ソフトウェア・プラットホーム設計情報を収めているコンポーネント・モデルは、最上位コンポーネントのＣＤＬとして記述される（１１１０）。PRODUCT_TYPE変数は、ソフトウェア製品によって設定値が変わる下位変数の値を分類して連動させており、PRODUCT_TYPE変数が有することができる値の目録通りに、makefile.config_decision内には、１１２２のように注釈処理された形態の実行ラインが追加される。PRODUCT_TYPE変数として設定された基本値（default value）は、１１２１のように注釈のない実行ラインとして追加される（１１２０）。] 図１１
[0131] 図１２は、ソフトウェア製品設定のためのビルトスクリプトであるmakefile．config_option構成の実施形態を示す。] 図１２
[0132] 図１２は、最上位コンポーネントのＣＤＬ
１２１０内に含まれた、PRODUCT_TYPEの各値に連動された下位変数の設定目録を記述するmakefile.config_optionの構成を示している。このとき、１２２４のようにマクロ（macro）を設定するための実行ラインが追加されるが、この段階では、PRODUCT_TYPEの設定値が反映されたマクロが宣言される。マクロは、ビルドスクリプト内で宣言され、ソースファイル内部で参照して活用できる運営体制のメカニズムである。１２２１は、先行するmakefile.config_decisionを参照することによって、いかなるPRODUCT_TYPEが選択されたかを確認することができる（１２２０）。] 図１２
[0133] 図１３は、設定変数のマッピングのためのビルドスクリプトであるmakefile．config_mapping構成の実施形態を示す。] 図１３
[0134] 図１３は、最上位コンポーネントに含まれた下位コンポーネント１３１０に分布された、他の設定変数間のマッピング関係による設定値を記述するmakefile.config_mappingを示している。１３２１は、先行するmakefile.config_optionで決定された設定値を参照するために含まれる。１３２２と１３２３は、それぞれ複合コンポーネントと基本コンポーネントとのために生成された設定変数の構成を示している。１３２２は、ＣＤＬ構成と同じ形態であり、上位（Level１）設定変数の設定値によって、下位（Level２）設定変数が有することになる値を指定している。ソフトウェア・プラットホーム内のあらゆる複合コンポーネントに係わる設定変数のマッピング関係が、かような方式でいずれも記述される。１３２３は、最も下位に位置することになる基本コンポーネントの可変性調整のための設定変数と、その設定値によるマクロ設定とを示している。コンポーネントに係わる可変性は、基本的にコンポーネントの組み合わせ過程への参与いかんを表現するためのオプション可変性を拡張したものである。すなわち、階層的構造と設定変数との関係を介して、最終的に、下位の基本コンポーネントが含まれているか否かを決定するためのものである。当該基本コンポーネントが含まれる設定値の場合、１３２４のようにマクロを宣言することによって、ソースファイル内部で参照して活用できる。このとき、マクロを累積して含むために、「DEFINE」変数は、「＋＝」を使用する（１３２０）。] 図１３
[0135] 図１４は、コンポーネントビルド経路のためのビルドスクリプトであるmakefile．config_path構成の実施形態を示す。図１４は、各コンポーネントの実際のソースコードが位置した経路を指定するためのmakefile.config_pathの構成を示している。１４１１は、先行するmakefile.config_mappingを参照するために含まれる。１４１２は、ソースコードをビルドするための運営体制のコンパイラ（compiler）を指定しており、１４１３は、最上位コンポーネントが位置することになる実際のシステム内での経路及びビルド過程に必要な経路情報を記述する。１４１２と１４１３は、仮想のプラットホーム生成部が提供するユーザ入力ツールを介して設定できる。１４１４は、複合コンポーネントの経路情報の構成を示しているが、最終的にビルドされて生成されるライブラリファイル目録も、設定変数の設定によって含まれるか否かが決定されるように自動的に設定される。ここでも、下位コンポーネントのライブラリを累積して含むために、「＋＝」を使用する。１４１５は、基本コンポーネントの経路情報構成を示している。それらの経路情報は、各複合コンポーネント及び基本コンポーネントの個別makefile内部に使われ、必要な位置情報を提供することになる。] 図１４
[0136] 図１５は、複合コンポーネントのmakefile構成の実施形態を示している。図１５を参照するに、上位（Level１）の複合コンポーネントは、下位（LevelＮ）に含まれたコンポーネントの設定変数設定値によって、当該コンポーネントのmakefile呼び出しいかんが決定されるように自動構成される。１５１１は、ビルド対象ソースコードの位置経路を把握するために含まれる。１５１２は、makefileの基本進入経路として一般的である「ａｌｌ」ビルドターゲット（build target）を含めたものであって、実際には、１５１３の当該コンポーネント名称と同じビルドターゲットを指す。１５１４は、生成されたライブラリファイルを除去するためのビルドターゲットである。] 図１５
[0137] 図１６は、基本コンポーネントのmakefile構成の実施形態を示している。図１６を参照するに、基本コンポーネントは、１５２１で、経路情報参照のためにmakefile.config_pathを含んでおり、１５２２では、自体の経路に存在するソースファイル目録及びヘッダファイル参照のための経路を構成している。１５２３では、ライブラリファイルの生成を実行し、１５２４では、ライブラリファイル除去のための実行ラインを構成する。] 図１６
[0138] 図１７は、呼び出しグラフ無欠性確認（call graph integrity check）コードの実施形態を示している。図１７を参照するに、コンポーネントのソースコードファイルには、提供／要請インターフェース内部の各関数集合が呼び出す他関数情報によって、関数呼び出しコードが自動的に含まれる。] 図１７
[0139] すなわち、コンポーネント・モデル設計段階で指定された各コンポーネント間の連動関係及び各関数が呼び出す他関数目録によって（１７１０）、ソースファイル内部の当該関数には、関数呼び出しのためのコール（call）構文が含まれる（１７２０）。これと共に、各関数は、自体が呼び出される場合に、呼び出し追跡性を提供するための呼び出しグラフ無欠性確認コード（call graph integrity check code）を含んでおり、構文形式は、自体が定義されたコンポーネントと自体の関数名称とが含まれる。]
[0140] 従って、ソフトウェア・プラットホームの設定とビルドとの後、ランタイム（runtime）時に、各関数が呼び出した関数に係わる無欠情確認コードの遂行結果が蓄積され、設計情報との一致いかんを確認することになる。]
[0141] 図１８は、呼び出しグラフ無欠性確認テーブル（call graph integrity check table）の実施形態を示している。図１８を参照するに、ソフトウェア・プラットホーム内のあらゆるコンポーネントと、各コンポーネントが有するようになる関数目録とを中心に、各関数が呼び出すことになる他関数目録が羅列される。もし呼び出された関数がさらに他の関数を呼び出すならば、目録内の当該コンポーネントと関数位置とから、もう一度追跡がなされる。ソフトウェア製品ごとに異なるコンポーネント構成及び可変性によって、各製品別に確認される関数呼び出しの目録は変わりうる。ソフトウェア・プラットホーム設計情報から呼び出しグラフの基本形態が定義され、仮想プラットホーム実行時に、追跡経路によって設計された地点及び他の地点での呼び出しが発生すれば、呼び出し無欠性エラーを発生させる。] 図１８
[0142] 以上で説明した仮想プラットホーム生成の各要素を総合し、ソフトウェア・プラットホーム・アーキテクチャ設計情報から仮想プラットホームを生成する過程について述べれば、次の通りである。]
[0143] １）コンポーネント・モデルに含まれたあらゆるコンポーネント、インターフェース、連結、可変性要素を、それぞれのコンポーネント・ハンドラ、インターフェース・ハンドラ、連結ハンドラ、可変性ハンドラを介して分析する。]
[0144] ２）最上位コンポーネントから最下位基本コンポーネントに至るまで、順次に必要な生成作業を進める。複合コンポーネントは、当該名称と同じディレクトリだけを生成することになり、基本コンポーネントは、コンポーネント・ディレクトリと共に、テンプレート・ソースコードを生成することになる。]
[0145] ３）可変性のための設定変数が当該コンポーネントに指定されている場合、条件文（conditional statement）を追加する。]
[0146] ４）ソースファイル作業後、ビルドスクリプト生成が進められる。]
[0147] ５）あらゆるコンポーネントに係わるテンプレート・ソースコードが生成されれば、仮想プラットホーム生成が完了する。]
[0148] 前記仮想プラットホーム生成の過程中、特に、ビルドスクリプト生成過程について具体的に述べれば、次の通りである。]
[0149] １）コンポーネント・モデルからソフトウェア製品の目録情報を把握する。]
[0150] ２）把握されたソフトウェア製品目録情報によって、makefile.config_decisionスクリプト内に、注釈処理形態であらゆる製品の設定ラインを追加する。このとき、目録情報のうち「default」項目は、注釈処理が除去され、ビルド実行時に、まず選択項目として動作できるようにする。]
[0151] ３）各製品タイプの設定変数をmakefile.config_optionスクリプト内に製品別に記述する。]
[0152] ４）makefile.config_mappingスクリプト内には、makefile.config_optionスクリプト内で各設定変数とマッピング関係にある下位設定変数の設定値を記述する。]
[0153] ５）各コンポーネントのソースコード位置情報を記述するためのmakefile.config_pathスクリプトを作成する。]
[0154] ６）最終的に、複合コンポーネントについては、下位コンポーネントに係わるビルドスクリプトを含むように構成されたビルドスクリプトを作成し、基本コンポーネントについては、基本コンポーネントのビルドがなされることができるように構成されたビルドスクリプトを作成することになる。]
[0155] 前記の通りに仮想プラットホームが生成された後には、これを利用してソフトウェア製品を組み合わせられるように、前記仮想プラットホームを設定する過程が行われる。]
[0156] 仮想プラットホームを設定する過程は、ソフトウェア・プラットホーム設計情報によって生成された仮想プラットホームを、設計構成によって多様な組み合わせとして設定し、各ソフトウェア製品構成が正常になされているか否かを確認する過程である。]
[0157] ソフトウェア・プラットホームは、多様なソフトウェア製品の構成部品であるコンポーネントの集合体であり、異なる構成を有するソフトウェア製品は、ソフトウェア・プラットホームの構成設定を介して、当該コンポーネントの組み合わせとして生成されうる。]
[0158] 生成された仮想プラットホームのテンプレート・ソースコードとビルドスクリプトとの内部には、ソフトウェア製品別に異なる設定を行うための設定変数が反映されて存在する。それら設定変数の設定値を変更し、これによってビルド及び実行結果を確認することによって、ソフトウェア・プラットホーム設計情報のエラー検出及び適合性検証を行うことができる。]
[0159] 以下、ソフトウェア・プラットホーム・アーキテクチャ設計情報に係わるコンポーネント・モデル検証（validation）を行う過程について述べれば、次の通りである。]
[0160] １）当該ソフトウェア・プラットホームから生成可能なソフトウェア製品別に、設定とビルドとの過程が進められる。最初のソフトウェア製品のための設定値として、makefile.config_decision内の設定変数をセッティングする。]
[0161] ２）ビルドが行われれば、各makefile間の設定変数連動情報及びソースコード経路を把握し、当該ソフトウェア製品の設定がなされる。]
[0162] ３）ビルドの結果、当該ソフトウェアを実行させ、関数呼び出しフローを追跡記録する。]
[0163] ４）設計と同じコンポーネント目録と関数呼び出しフローとが確認されれば、当該ソフトウェア製品については、設計情報が検証されたと評価する。]
[0164] ５）残りの製品タイプについても順次に検証を行い、あらゆる製品タイプについて設計情報と同一である場合、当該ソフトウェア・プラットホームのコンポーネント・モデル設計は、異常なく構成されたと判断できる。]
[0165] 一方、前述の本発明の方法は、コンピュータで実行できるプログラムで作成可能であり、コンピュータで読取り可能な記録媒体を利用し、前記プログラムを動作させる汎用デジタル・コンピュータで具現されうる。]
[0166] また、前述のように、本発明で使われたデータの構造は、コンピュータで読取り可能な記録媒体にいくつかの手段を介して記録されうる。]
[0167] 前記コンピュータで読取り可能な記録媒体は、マグネチック記録媒体（例えば、ＲＯＭ（read-only memory）、フロッピー（登録商標）ディスク、ハードディスクなど）、光学的判読媒体（例えば、ＣＤ−ＲＯＭ、ＤＶＤなど）及びキャリアウェーブ（例えば、インターネットを介した伝送）のような記録媒体を含む。]
[0168] 以上、本発明についてその望ましい実施形態を中心に述べた。本発明が属する技術分野で当業者であるならば、本発明が本発明の本質的な特性から外れない範囲で変形された形態で具現されうることを理解することができるであろう。従って、開示された実施形態は、限定的な観点ではなくして、説明的な観点から考慮されねばならない。本発明の範囲は、前述の説明ではなくして、特許請求の範囲に示されており、それと同等な範囲内にあるあらゆる差異点は、本発明に含まれるものであると解釈されねばならない。]

权利要求:

請求項1
コンポーネント・モデル基盤の仮想ソフトウェア・プラットホームを生成する方法において、ソフトウェア・プラットホームの受信された設計情報によって、ソフトウェアの少なくとも一つ以上のコンポーネントの機能を記述するテンプレートコードを生成する段階と、前記ソフトウェアの種類による設定変数が備わり、前記生成されたテンプレートコードのビルドを行うビルドスクリプトを生成する段階と、を含むことを特徴とする生成方法。
請求項2
前記テンプレートコードを生成する段階は、前記少なくとも一つ以上のコンポーネントのうち、上位コンポーネント及び下位コンポーネントの包含関係を示すディレクトリ構造を生成する段階と、前記少なくとも一つ以上のコンポーネントのうち、第１コンポーネントのインターフェースと、前記インターフェースを使用する第２コンポーネントとの依存関係を示す依存性要素を反映する段階と、前記設定変数によって、前記包含関係または前記依存関係にある複数個の前記コンポーネントを選択する可変性要素を反映する段階と、をさらに含むことを特徴とする請求項１に記載の生成方法。
請求項3
前記ディレクトリ構造は、階層的ディレクトリ構造であり、前記階層的ディレクトリ構造のボトムレベル・コンポーネントは、ヘッダファイル及びソースファイルに係わる別途の下位ディレクトリを有することを特徴とする請求項２に記載の生成方法。
請求項4
前記第２コンポーネントのソースコードは、前記第１コンポーネントのヘッダファイルに係わる参照、及び前記第１コンポーネントの前記インターフェースに対応する機能に係わる呼び出しを含むことを特徴とする請求項２に記載の生成方法。
請求項5
前記ビルドスクリプトを生成する段階は、前記ソフトウェアの種類を選択するタイプ変数を定義する段階と、前記タイプ変数に連動された下位設定変数を記述する段階と、設定変数間のマッピング関係によって設定値を指定する段階と、前記コンポーネントそれぞれのソースコードの経路情報を設定する段階と、をさらに含むことを特徴とする請求項２に記載の生成方法。
請求項6
前記設定値を指定する段階は、前記設定値を下位コンポーネントに分配する段階を含むことを特徴とする請求項５に記載の生成方法。
請求項7
前記ビルドスクリプトを生成する段階は、前記可変性要素を反映するように、前記ビルドスクリプト内に条件文を追加する段階をさらに含むことを特徴とする請求項５に記載の生成方法。
請求項8
前記可変性要素は、所定のコンポーネントを前記ビルドスクリプトの経路から除外させるオプション可変性または設定変数の設定値によって、所定のコンポーネントを選択するスイッチ可変性であることを特徴とする請求項７に記載の生成方法。
請求項9
前記ビルドスクリプトを生成する段階は、複合コンポーネントに係わって、下位コンポーネントに係わるビルドスクリプトを再帰的に呼び出すように、前記ビルドスクリプトを構成する段階と、基本コンポーネントに係わって、前記基本コンポーネントのソースコードに係わるビルドプロセスを記述するように、前記ビルドスクリプトを構成する段階と、を含むことを特徴とする請求項８に記載の生成方法。
請求項10
コンポーネント・モデル基盤のソフトウェア・プラットホーム・アーキテクチャの検証方法において、ソフトウェア・プラットホームの設計情報によって、ソフトウェアの少なくとも一つ以上のコンポーネントの機能を記述するテンプレートコード、及びソフトウェア種類による設定変数が備わり、前記生成されたテンプレートコードのビルドを行うビルドスクリプトを具備する仮想ソフトウェア・プラットホームを生成する段階と、前記コンポーネントの組み合わせのために、前記仮想ソフトウェア・プラットホームに提供された設定変数の設定値を変更する段階と、前記変更された設定変数に基づいた前記仮想ソフトウェア・プラットホームの実行結果によって、前記ソフトウェア・プラットホームの整合性を検証する段階と、を含むことを特徴とする検証方法。
請求項11
前記設定変数の設定値を変更する段階は、コンポーネントに提供された可変性要素を設定する段階と、前記設定によって、前記仮想ソフトウェア・プラットホームをビルドする段階と、をさらに含むことを特徴とする請求項１０に記載の検証方法。
請求項12
前記可変性要素は、上位可変性要素であることを特徴とする請求項１１に記載の検証方法。
請求項13
前記検証する段階は、前記ソフトウェア・プラットホームの前記受信された設計情報から獲得された呼び出しグラフ、及び前記仮想ソフトウェア・プラットホームの実行による関数呼び出しグラフを比較する段階と、前記比較に基づいて、前記ソフトウェア・プラットホームの依存性及び／または無欠性を判断する段階と、をさらに含むことを特徴とする請求項１１に記載の検証方法。
請求項14
前記検証する段階は、前記ソフトウェアの製品明細の内容と、前記仮想ソフトウェア・プラットホームの実行による前記少なくとも一つ以上のコンポーネントのディレクトリ構成とを比較する段階と、前記比較に基づいて、前記変更された設定値によるソフトウェアに係わる前記設計情報を検査する段階と、をさらに含むことを特徴とする請求項１１に記載の検証方法。
請求項15
前記コンポーネント・モデルの構成要素であるコンポーネント、インターフェース、連結、可変性要素のうち、前記コンポーネント・モデルの少なくとも一つ以上の構成要素に係わる目録を管理する段階をさらに含むことを特徴とする請求項１４に記載の検証方法。
請求項16
前記コンポーネント・モデルの前記少なくとも一つ以上の構成要素に係わる目録を管理する段階は、前記コンポーネントに備わった可変性要素に対応する変数を定義するための言語構文を処理する段階をさらに含むことを特徴とする請求項１５に記載の検証方法。
請求項17
前記仮想ソフトウェア・プラットホームを生成する段階は、前記少なくとも一つ以上のコンポーネントのうち、上位コンポーネント及び下位コンポーネントの包含関係を示すディレクトリ構造を生成する段階と、前記少なくとも一つ以上のコンポーネントのうち、第１コンポーネントのインターフェースと、前記インターフェースを使用する第２コンポーネントとの依存関係を示す依存性要素を反映する段階と、前記設定変数によって、前記包含関係または前記依存関係にある複数個の前記コンポーネントを選択する可変性要素を反映する段階と、をさらに含むことを特徴とする請求項１０に記載の検証方法。
請求項18
コンポーネント・モデル基盤の仮想ソフトウェア・プラットホームを生成する装置において、ソフトウェア・プラットホームの受信された設計情報によって、ソフトウェアの少なくとも一つ以上のコンポーネントの機能を記述するテンプレートコードを生成するコード生成部と、前記ソフトウェアの種類による設定変数が備わり、前記生成されたテンプレートコードのビルドを行うビルドスクリプトを生成するビルドスクリプト生成部と、を含むことを特徴とする生成装置。
請求項19
前記コード生成部は、前記少なくとも一つ以上のコンポーネントのうち、上位コンポーネント及び下位コンポーネントの包含関係を示すディレクトリ構造を生成し、前記少なくとも一つ以上のコンポーネントのうち、第１コンポーネントのインターフェース及び前記インターフェースを使用する第２コンポーネント間の依存関係を示す依存性要素を反映し、前記設定変数によって、前記包含関係または依存関係にある複数個の前記コンポーネントを選択する可変性要素を反映することを特徴とする請求項１８に記載の生成装置。
請求項20
前記ディレクトリ構造は階層的ディレクトリ構造で、前記階層的ディレクトリ構造のボトムレベル・コンポーネントは、ヘッダファイル及びソースファイルに係わる別途の下位ディレクトリを有することを特徴とする請求項１９に記載の生成装置。
請求項21
前記第２コンポーネントのソースコードは、前記第１コンポーネントのヘッダファイルに係わる参照、及び前記第１コンポーネントの前記インターフェースに対応する機能に係わる呼び出しを含むことを特徴とする請求項１９に記載の生成装置。
請求項22
前記ビルドスクリプト生成部は、前記ソフトウェアの種類を選択するタイプ変数を定義し、前記タイプ変数に連動された下位設定変数を記述し、設定変数間のマッピング関係によって設定値を指定し、前記コンポーネントそれぞれのソースコードの経路情報を設定することを特徴とする請求項１９に記載の生成装置。
請求項23
前記ビルドスクリプト生成部は、前記設定値を下位コンポーネントに分配することによって、前記設定値を特定することを特徴とする請求項２２に記載の生成装置。
請求項24
前記ビルドスクリプト生成部は、前記可変性要素を反映するように、前記ビルドスクリプト内に条件文を追加することを特徴とする請求項２２に記載の生成装置。
請求項25
前記可変性要素は、所定のコンポーネントを前記ビルドスクリプトの経路から除外させるオプション可変性、または設定変数の設定値によって所定のコンポーネントを選択するスイッチ可変性を含むことを特徴とする請求項２４に記載の生成装置。
請求項26
複合コンポーネントに係わって、前記ビルドスクリプト生成部は、下位コンポーネントに係わるビルドスクリプトを再帰的に呼び出すように、前記ビルドスクリプトを構成し、基本コンポーネントに係わって、前記ビルドスクリプト生成部は、前記基本コンポーネントのソースコードに係わるビルドプロセスを記述するように、前記ビルドスクリプトを構成することを特徴とする請求項２５に記載の生成装置。
請求項27
コンポーネント・モデル基盤のソフトウェア・プラットホーム・アーキテクチャの検証装置において、ソフトウェア・プラットホームの受信された設計情報によって、ソフトウェアの少なくとも一つ以上のコンポーネントの機能を記述するテンプレートコード、及びソフトウェア種類による設定変数が備わり、前記生成されたテンプレートコードのビルドを行うビルドスクリプトを具備する仮想ソフトウェア・プラットホームを生成する仮想プラットホーム生成部と、前記コンポーネントの組み合わせのために、前記仮想ソフトウェア・プラットホームに備わった設定変数の設定値を変更する仮想プラットホーム設定部と、前記変更された設定変数に基づいた前記仮想ソフトウェア・プラットホームの実行結果によって、前記ソフトウェア・プラットホームの整合性を検証するアーキテクチャ検証管理部と、を含むことを特徴とする検証装置。
請求項28
前記仮想プラットホーム設定部は、コンポーネントに備わった可変性要素を設定し、前記設定によって、前記仮想ソフトウェア・プラットホームをビルドすることを特徴とする請求項２７に記載の検証装置。
請求項29
前記可変性要素は、上位可変性要素であることを特徴とする請求項２８に記載の検証装置。
請求項30
前記アーキテクチャ検証管理部は、前記ソフトウェア・プラットホームの前記受信された設計情報から獲得された呼び出しグラフ、及び前記仮想ソフトウェア・プラットホームの前記実行による関数呼び出しグラフを比較し、前記比較に基づいて、前記ソフトウェア・プラットホームの依存性及び／または無欠性を判断することを特徴とする請求項２８に記載の検証装置。
請求項31
前記アーキテクチャ検証管理部は、前記ソフトウェアの製品明細の内容と、前記実行による前記少なくとも一つ以上のコンポーネントのディレクトリ構成とを比較し、前記比較に基づいて、前記変更された設定値によるソフトウェアに係わる設計情報を検査することを特徴とする請求項２８に記載の検証装置。
請求項32
前記コンポーネント・モデルの構成要素であるコンポーネント、インターフェース、連結、可変性のうち、前記コンポーネント・モデルの少なくとも一つ以上の構成要素に係わる目録を管理するコンポーネント・モデル管理部をさらに含むことを特徴とする請求項３１に記載の検証装置。
請求項33
前記コンポーネント・モデル管理部は、前記コンポーネントに備わった可変性要素に対応する変数を定義するための言語構文を処理するコンポーネント言語記述子をさらに含むことを特徴とする請求項３２に記載の検証装置。
請求項34
前記仮想プラットホーム生成部は、前記少なくとも一つ以上のコンポーネントのうち、上位コンポーネント及び下位コンポーネントの包含関係を示すディレクトリ構造を生成し、前記少なくとも一つ以上のコンポーネントのうち、第１コンポーネントのインターフェース及び前記インターフェースを使用する第２コンポーネント間の依存関係を示す依存性要素を反映し、前記設定変数によって、前記包含関係または依存関係にある複数個の前記コンポーネントを選択する可変性要素を反映することを特徴とする請求項２７に記載の検証装置。
請求項35
請求項１に記載の方法を具現するためのプログラムがエンコーディングされたコンピュータで読取り可能な記録媒体。
請求項36
請求項１０に記載の方法を具現するためのプログラムがエンコーディングされたコンピュータで読取り可能な記録媒体。
請求項37
ソフトウェア・プラットホーム・アーキテクチャの検証システムにおいて、前記検証システムは、コンポーネント・モデル基盤の仮想ソフトウェア・プラットホームを生成する装置と、コンポーネント・モデル基盤のソフトウェア・プラットホーム・アーキテクチャの検証装置と、を含み、前記コンポーネント・モデル基盤の仮想ソフトウェア・プラットホームを生成する装置は、ソフトウェア・プラットホームの受信された設計情報によって、ソフトウェアの少なくとも一つ以上のコンポーネントの機能を記述するテンプレートコードを生成するコード生成部と、前記ソフトウェアの種類による設定変数が備わり、前記生成されたテンプレートコードのビルドを行うビルドスクリプトを生成するビルドスクリプト生成部と、を含み、前記コンポーネント・モデル基盤のソフトウェア・プラットホーム・アーキテクチャの検証装置は、前記コンポーネントの組み合わせのために、前記仮想ソフトウェア・プラットホームに備わった設定変数の設定値を変更する仮想プラットホーム設定部と、前記変更された設定変数に基づいた前記仮想ソフトウェア・プラットホームの実行結果によって、前記ソフトウェア・プラットホームの整合性を検証するアーキテクチャ検証管理部と、を含むことを特徴とする検証システム。
請求項38
コンポーネント・モデル基盤のソフトウェア・プラットホーム・アーキテクチャの検証装置において、前記検証装置は、ソフトウェア・プラットホーム・アーキテクチャの設計情報によって、ソフトウェアの少なくとも一つ以上のコンポーネントの機能を記述するテンプレートコード、及びソフトウェア種類による設定変数が備わり、前記テンプレートコードのビルドを行うビルドスクリプトを具備する仮想ソフトウェア・プラットホームを使用し、前記コンポーネントの組み合わせのために、前記仮想ソフトウェア・プラットホームに提供された設定変数の設定値を変更する仮想プラットホーム設定部と、前記変更された設定変数に基づいた前記仮想ソフトウェア・プラットホームの実行結果によって、前記ソフトウェア・プラットホームの整合性を検証するアーキテクチャ検証管理部と、を含むことを特徴とする検証装置。